Enterprise software systems are generally large and complex. Such systems can require many different components, distributed across many different hardware platforms, possibly in several different geographical locations. In order to design, configure, update or implement an enterprise software system, one is generally required to understand details of the system at varying levels, depending on his role in designing, managing or implementing the system. For example, a systems administrator may need a high-level technical understanding of how various software modules are installed on physical hardware, such as a server device or a network, and how those software modules interact with other software modules in the system. A person responsible for configuring the software may utilize a high-level functional understanding of the operations that each functional component provides. An application designer may utilize a low-level technical understanding of the various software interfaces that portions of the application require or implement. An application developer may utilize a detailed understanding of the interfaces and functionality he is implementing in relation to the remainder of the system. But the flow of a business process within an application today is typically hidden from a user. In some cases, it is possible to manually create a textual or graphical documentation of this process flow. However, this documentation is typically not detailed enough and can become quickly outdated since its consistency with the actual application software is not (initially) verified or maintained automatically.
Within a development environment, an application can be developed using modeling systems. In general, these models can specify the types of development objects or components that can be used to build applications, as well as the relationships that can be used to connect those components. In an object-oriented architecture, for example, a defined application can include a combination of various data objects and resources (i.e., development objects). In that example, relationships among the development objects can include a relationship indicating that one data object inherits characteristics from another data object. Further, data objects and data object fields can have hierarchical relationships, with relationships between data objects and data object fields can be hierarchical, in that a data object is related to a second data object through a shared relationship with a third data object or data object field, etc.
Dedicated reporting and analytics modularity can also be provided with enterprise software deployments. While certain flows, functionality, and infrastructure may be hidden from enterprise customers to protect enterprise system integrity, in addition to modeling, customers can be provided with customized reporting and querying functionality in connection with the enterprise software deployment. To protect functionality and infrastructure of the system, specialized query data structures can be developed drawing from data structures and data relationships of the system and delivered applications, that can be used in connection with the reporting module to process queries relating to the data structures upon which the specialized query data structures are based. Where specialized query data structures do not yet exist for an underlying data structure, the specialized query data structures can be “staged” by developers, in essence converting the underlying data structure and its relational attributes within the system into a corresponding query data structure capable of being processed and queried by the reporting module. Staging of specialized data structures and conversions into query data structures can involve the creation of unique data conversion modules, or agents, specialized to handle the underlying data structure and corresponding data conversion type.